Data communication systems exchange user data for user devices to provide various data communication services. The user devices may be phones, computers, media players, and the like. The data communication services might be media streaming, audio/video conferencing, data messaging, or internet access. Software-Defined Networks (SDNs) have become a popular data communication system to deliver these data communication services.
An SDN has applications, controllers, and data machines. The SDN controllers expose network-level control-plane Application Programming Interfaces (APIs) to the SDN applications. The SDN applications call these SDN controller APIs to implement the data communication services. In a like manner, the SDN data machines expose network-level data-plane APIs to the SDN controllers. The SDN controllers call these SDN data machine APIs to implement the data communication services. The SDN data machines process user data in response to the SDN data machine API calls.
For example, an SDN application may determine that an update to an SDN Flow Descriptor Table (FDT) is required to support a user data service. The SDN application calls a controller API with the FDT update. The SDN controller calls a data machine API with the FDT update. The SDN data machine updates its FDT responsive to the data machine API call from the SDN controller. Subsequently, the SDN data machine receives user data packets, matches the packet addresses to an action in the updated FDT, and performs the action on the user data packets. The SDN data machines may forward, drop, or store the user data packets based on the FDT.
Many SDNs execute on Network Function Virtualization (NFV) computer systems. NFV computer systems have Virtual Network Functions (VNFs) that perform like typical communication network elements or portions of these network elements. The VNFs run under the control of a virtual layer (hypervisors, virtual containers, NFV controllers) that control VNF access to NFV hardware (circuitry, memory, communication interfaces). The virtual layer also controls the NFV thread (processing time cycle) for the VNFs. To implement a data communication service, an NFV Management and Orchestration (MANO) system drives the NFV hardware to execute and support the VNFs based on various network service descriptors for the data communication service.
In NFV SDN systems, the VNFs may be SDN applications, SDN controllers, and SDN virtual data machines. The SDN application VNFs communicate with one another by transferring Virtual Data Units (VDUs) or Virtual Machines (VMs). The VNFs use NFV SDN virtual Switches (vSWs) to transfer the VDUs/VMs between each other. Thus, vSWs provide the basic connectivity between SDN VNFs.
Hardware trust entails the exchange of trust data with a processing system to validate the identity of the hardware used by the processing system. Typically, a hardware trust server stores a secret security key that is also physically embedded into the processing system. The hardware trust server and issues a random number to the processing system. The processing system hashes the random number with its secret, physically-embedded security key to generate a trust result for the hardware trust server. The hardware trust server hashes the random number with its own stored security key to verify the trust result and establish hardware trust with the processing system.
Unfortunately, the ability of NFV VNFs to communicate with one another over SDN vSWs is not adequate. In particular, the integration of hardware trust into the SDN vSWs that operate in NFV systems is inefficient and ineffective.
Technical Overview
A Network Function Virtualization Infrastructure (NFVI) maintains hardware-trusted communications. In the NFVI, a hardware-trust controller executes at a Ring 0 security level. A target Virtual Switch (vSW) executes under control of the hardware-trust controller. The hardware-trust controller transfers hardware-trust data to the target vSW that indicates hardware-trusted vSWs. The target vSW receives a Virtual Data Unit (VDU) from a source vSW. The target vSW transfers the VDU when the source vSW is one of the hardware-trusted vSWs. The target vSW blocks the VDU when the source vSW is not one of the hardware-trusted vSWs.